This page contains my suggestions on documentation style. I will try to demonstrate my suggestions by writing a document that justifies them. I'm an advocate of learning by example. As Mark Twain said, "Few things are harder to put up with than the annoyance of a good example" (Samuel Langhornne Clemens (1835-1910)).

Pulling content from CVS

A large part of the WebWork 2.2 documentation effort is to make documentation easier to handle in the future. At on the onset of this effort, everyone agreed that pulling as much source code, examples, and documentation from source control would help greatly. As such, we've installed a modified version of the snippet macro in the OpenSymphony wiki.

Important! Whenever you write documentation, ask yourself if you can somehow have this documentation checked in to source control in the form of example code or JavaDocs. This will make the documentation much more likely to be useful for years to come.

The standard way to use it is to do the following:

{snippet:id=description|javadoc=true|url=com.opensymphony.xwork.interceptor.LoggingInterceptor}

or

{snippet:id=example|javadoc=true|lang=xml|url=com.opensymphony.xwork.interceptor.LoggingInterceptor}

or

{snippet:id=sitegraph-usage|lang=none|url=webwork/src/java/com/opensymphony/webwork/sitegraph/sitegraph-usage.txt}

or

{snippet:id=ajax-validation-example|lang=xml|url=webwork/webapps/ajax/src/webapp/lesson1/example.jsp}

Where:

• id is the name of the snippet (*required).
• url is the URL where the snippet can be found (required).
• lang is the language that the code block should be required as. If this snippet is simply text, don't include this parameter and the content will be printed outside of a code block.
• javadoc indicates if the content is within a JavaDoc block. If this is set to true, then the preceeding "* " (asterisk-space) characters will be stripped before printing the content out. Also, the content is assumed to the HTML escaped already and therefore won't be escaped again.

All snippets are marked off by the pattern START SNIPPET: XXX and END SNIPPET: XXX where XXX is the name of the snippet that is assigned in the id attribute of the macro. The URL is typically a location that points to the project's source control contents.

A note about URLs

As you probably noticed in the examples, there are several formats that the URL patterns can be in. A fully-qualified URL is always allowed, though that is often not practical. We've customized the macro to be a bit more intelligent with the URL attribute:

• If the URL appears to be a class, we assume it lives in src/java, convert all the dots to slashes, and then append .java to it.
• If the URL doesn't start with "http", then it is assumed to start with _https://opensymphony.dev.java.net/source/browse/*checkout*/_, as you saw in the third example.

Note that the short-hand class notation will only work for top-level projects (WebWork, OSWorkflow, etc) and not any sub-projects within the projects, such as example webapps in WebWork. If you wish to include content from a class in a sub-project, you'll need to list out the full path, like in the fourth example.

A note about snippet markers

All snippet markers should be commented out if possible. How they are commented out depends on where the snippet is. If the snippet is for HTML or XML, you can do:

<!-- START SNIPPET: xxx -->
...
<!-- END SNIPPET: xxx -->

If the snippet is in Java code, you can do:

if (true != false) {
    // START SNIPPET: xxx
    System.out.println("This is some silly code!");
    // END SNIPPET: xxx
}

If the snippet is found in JavaDocs, you should use HTML comments as they won't render in the JavaDocs. For XML examples in JavaDocs (see Timer Interceptor for an example), it can be a bit tricky. This is because in your JavaDocs you want to use the <pre> tag, but you don't want the wiki to display it. A good technique is to embed the snippet markers inside the <pre> tag:

* <pre>
 * <!-- START SNIPPET: example -->
 * &lt;!-- records only the action's execution time --&gt;
 * &lt;action name="someAction" class="com.examples.SomeAction"&gt;
 *     &lt;interceptor-ref name="completeStack"/&gt;
 *     &lt;interceptor-ref name="timer"/&gt;
 *     &lt;result name="success"&gt;good_result.ftl&lt;/result&gt;
 * &lt;/action&gt;
 * <!-- END SNIPPET: example -->

About Headings

This section refers to: Notation Guide >> Headings.

Headings should definetly be used. This sections tries to justify why.

First rule: don't use "h1" at the top of each page. The page title serves as the "top level header" already, so there is no need to duplicate that information again. Also, when the docs end up the website, SiteMesh will place a top level "h1" element using the page title.

Document sections

Headings can help you divide your document in sections, subsections, sub-subsections and so forth.

Advantages

Your document becomes more organized.

Disadvantages

If you exaggerate you could fragment your text too much.

Warning This is definetly an example of this, since this whole "Headings" section has such few paragraphs that it really should have been written in just one section. Aren't warning boxes neat?

Headings capitalization

I think headers h1 and h2 should have all words capitalized (such as "Vitor's Suggestions on Documentation Style" and "About Headings"), but h3 and smaller would have just the first word (such as "Headings capitalization"). Except, of course, for words that are always capitalized (eg. "Understanding WebWork's importance to OpenSymphony and its community"). This gives even more importance to bigger headings.

Avoid skipping headers

I mean, avoid going from a h1 directly to a h3 without using h2 before. This would be like havin a section 1.1.1 directly below section 1, without the existance of section 1.1.

Handy Hint One thing that I like to do is leave five blank lines before h1 headings, three before h2's and two before h3's. Also, in Portuguese (I'm Brazilian), we write small numbers using their names instead of numeric representation (five instead of 5). I don't know if this is also a good practice in written english. Aren't tip boxes neat?

Be Careful If you find yourself writting too many h1 headings in a single page, consider breaking the page into child pages and linking to them. Aren't note boxes neat?

More on Text Effects

This section refers to: Notation Guide >> Text Effects.

Text effects should be largely used, although I have some questions on some of them. Strong, emphasis, and inserted can be used to denote importante parts of a sentence. But I really think inserted should have been called underline in the notation guide. I don't see the point of using deleted, since when someone changes a page and deletes stuff, Confluence keeps the old versions in history.

I can't think of a situation in WebWork's doc for ^superscript and _subscript, but it doesn't hurt to mention them. I can't say anything about %span% because I frankly don't know what it does. Monospaced is heavily used, for instance, to refer to webwork-default.xml file or items in source code examples: <xmltag />, JavaClass or javaVariable.

Boxes vs. Block Quotes I think boxes and block quotes do the same job, but boxes are better. Therefore, I suggest we don't use block quotes. Aren't info boxes neat? Aren't them all neat? By now you may have realized I think we should definetly use them...

Colors should be used in very specific cases, or else each documentation writers would color his/her pages the way he/she thinks it's better, and it would look like a mess. One such specific case in which colors can help is when you want them to work as tags or captions. For (a lame) example, in this paragraph, guidelines are in red and justifications are in blue. Yes, it's a really really lame example, I know.

Text Breaks

This section refers to: Notation Guide >> Text Breaks.

Text breaks shouldn't be used. If you'd like paragraphs or headings to have more spacing (before or after), the style sheet should be changed, not the contents. Patrick explained this a long time ago. Other stuff in this section (paragraphs, horizontal ruler, — symbol and – symbol) can be used when necessary.

Links

This section refers to: Notation Guide >> Links.

All types of links can and should be used. I already used a few in this document. Just watch out for links to non-existing pages when writing on the official documentation.

Lists

This section refers to: Notation Guide >> Lists.

Lists can be used for many purposes. Every time we list some things that are in order, ordered lists are used. If they don't have a specific order, unordered lists are the case. List should be nested if needed for a better organization. Unordered lists should be created only with the * (star) notation only, so all pages use the same style of bullet.

• This is an unordered list in star notation;
• Items can have sub-items
  • That can have sub-items
    • That can have sub-items...
      • What is the limit?
• Mixing ordered and unordered lists is possible:
  1. One;
  2. Two;
  3. Three.

List indentation Use tabs to indent nested lists. This way your page's markup is more readable and easier to maintain.

Images and Icons

This section refers to: Notation Guide >> Images and Notation Guide >> Misc.

External images should be used only when strictly necessary (meaning, don't use images as list bullets or box icons). Also, try to use only images that are very unlikely to be removed from its current URL, to reduce document maintenance. Pay attention on copyright issues too! Attached images are less prone to become missing links, however, we should not clutter the documentation with unnecessary attachments and copyrights are also a issue here.

Example: Cannot resolve external resource into attachment.

Icons are cool in a number of situations. Some of them, such as , , or can make the documentation look professional, but some others, such as and may give a feeling of amateurship and I wouldn't advise them for pages that are exported to form the official documentation.

Tables

This section refers to: Notation Guide >> Tables.

Tables are very useful when lists just don't do it. Meaning: don't write a table when a list suffices. Tables are more organized, because you can align the text in columns. Since the markup text for tables in confluence is not very easy to read, remember complex and big tables are very hard to maintain.

The table below was copied from a reference page on WebWork's configuration (just the first two lines were copied). This is an example where tables are good: a list wouldn't be as organized as this table to display these files and their properties.

Advanced Formatting

This section refers to: Notation Guide >> Advanced Formatting.

I've already made my point about info, warning, tip and note boxes. Other interesting markups are noformat and code. The former can be used for general purpose text while the latter is used to display example source code, be it HTML, XML, Java or anything that is part of a software solution. When displaying something that has a name, use a title, as the example below demonstrates.

/** Hello World class. */
public class HelloWorld {
  /** Main method. */
  public static void main(String[] args) {
    System.out.println("Hello, World!");
  }
}

A typical example of noformat would be the command line statements to compile and run the code above. We should also standardize terminal notation ({$} for command prompt).

$ javac HelloWorld.java

$ java HelloWorld
Hello, World!

Do not use tabs inside noformat and code, use two spaces instead. This way your code is indented but keeps lines short. Large lines should be splitted as to fit in a 800x600 resolution screen without horizontal scroll bars.

Your Comments Please

Please contribute to this page. Let me know if you have a different opinion on something (please justify it). Please warn me if I wrote something wrong or if this proposed Style Guide is missing something. Feel free to correct my english, since I'm not a native speaker.